1. Field
Embodiments of the present invention generally relate to business intelligence (BI) systems and systems and methods for performing enterprise-level analysis and reporting of transaction information. More specifically, embodiments of the present invention provide a multi-level advanced caching engine that is designed for processing a high-volume of transaction data and ensuring high performance query processing.
2. Description of Related Art
One of the key issues decision makers in corporations face today is finding out how the business is doing, planning for the future, measuring performance against plan, being able to determine when and how a plan might need to be changed in response to internal and external events and ensuring that the organization meets regulatory requirements. This requires that reports and other financial applications are able to work with data from more than one system and the systems of more than one sub-entity (division, country office, etc.).
Traditionally, databases (namely data marts, data warehouses and Online Analytical Processing (OLAP) cubes that are multi-dimensional) would be the central part of any system implementation that attempts to provide business intelligence for any company to make informed decisions. Traditionally, the BI projects would be information technology (IT)-intensive, and requires substantial upfront time for setting up metadata (data about the numeric values) and continues to require IT involvement in making adjustments to the structure/layout of the data warehouse.
In a typical BI/data warehouse implementation, Extraction, Transformation and Loading (ETL) jobs would be setup to transform diverse data sources; data would be loaded and aggregated based on pre-determined business rules; databases might be replicated so users in different geographical locations (that might not be in the same network) could access data; reports and OLAP cubes would be designed, implemented and maintained by IT staff to support the ever changing business requirements.
The main short-coming of OLAP is that cubes are defined with a constrained and predetermined set of dimensions and hierarchies within those dimensions. It is not usually possible for a non-technical end user to define additional dimension hierarchies nor is it normal for the OLAP server to update itself with new dimensions when and if the underlying transactions indicates that new data attributes are available and that can be used as dimensions.
OLAP dimensionality is constrained because OLAP servers pre-aggregate all or at least most of the data and each new dimension added causes an exponential growth in the size of the aggregate data.
A major disadvantage of the constraints imposed using the approach taken by OLAP servers is that, generally, OLAP cubes are defined using only “first class” dimensions such as time, accounts, product, region. While a user can create a report based on these dimensions, a user cannot create an aggregate based on some other attribute of the data. For example, a dimension of the data may be “Store” and this dimension may have a hierarchy showing a regional aggregation of store data. However, a user may have a requirement to analyze store data grouped by zip code. While zip code may be an attribute of the store, which is available in the underlying transaction data, in the context of the present example, the OLAP user's solution to this problem of being able to consolidate data across zip codes is to ask for a new, permanent, hierarchy to be defined by making zip code a “first class” dimension even though this required aggregation might only be for a temporary purpose and only for a single user.
In view of the foregoing, it would be desirable to have a more flexible system that allows consolidation of data across multiple geographical locations, multiple functional areas and provides a uniform view to users in an enterprise interactively and on a real-time basis without the need for hierarchy redefinition and significant involvement of IT personnel.